Thorsten Froehlich wrote:
> In article <3e3c4faa@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>
> wrote:
> 
>> The principle is to only render some pixels and calculate the color of
>> other pixels using interpolation.
>>
>> I read some papers which indicate that (if done properly) speed can be
>> increased by an order of magnitude while nearly not affecting quality
>> (depending on the scene, of course). The stuff in question is called
>> Directional Coherence Map.   [ Wow. Sounds cool, right? ;) ]
> 
> In simpler terms: It is a kind of adaptive antialiasing on pixel blocks.
> 
Kind of, yes. 
But the algorithm doing the adaption should be more clever than the 
current one and it is not about averaging supersample colors but 
guessing colors from fewer samples. 

>> 1. (Mosaic) Preview:
>>
>> The current mosaic preview adds rendering time because the pixels
>> rendered in the preview are not used in the final rendering.
> 
> Yes.  I know it is intentional, but I do not know why.
> 
One doesn't need a mosaic preview for the final rendering so there is no 
problem with additional time, I think. However, for a quick preview 
it would be nice to re-use the pixels like I do. 

>> 2.1. First, the povray code structure:
>>
>> Some easy modifications would have to made (better control when
>> plot_pixel() actually calls XPutImage() by adding a plot_flush(x,y,w,h)
>> function, etc).
> 
> I assume XPutImage is some platform specific function.  I am not sure
> where
> you are going here or what exactly you are talking about.  Please clarify.
> 
Okay the problem is simple:
Calling plot_pixel() should display the pixel on the screen (SVGAlib, X11 
or whatever). However, e.g. for X11, plot_pixel() just puts the pixel in 
offscreen storage and actually flushes the buffer once a complete image 
line was plotted (x coord == width-1) or some time elapses. 
Now, the problem is that I do not render lines from left to right, one 
at a time which breaks the simple update logic. 
So, I would introduce a flush function which explicitly tells 
the underlaying display routine to put some part on screen. For SVGAlib 
this would be a no-op. This would require a trivial one-line patch 
at two or three other positions where plot_pixel is used. 
Nothing really complicated. 

>> Do_Cooperate().
>>   Don't know when it should be called or if it can cope with the
>>   situation. Could someone enlighten me on POVMS? It seems to deal
>>   with "messages", "queues" and "objects" but I have no clue.
> 
> POVMS is a way to abstract the different output streams and render control
> in a way more suitable for GUI platforms.  It has nothing to do with the
> actual ray-tracing core.  In future releases of the POV-Ray 3.5.x the
> other means of handling output will be gradually removed and replaced by a
> POVMS-only system with default code for command-line versions.
> 
Okay, but when should I call Do_Cooperate()? And what does the param 
(int level) mean?
I always read something about "well documented" and "cleanly coded" 
patches to POVRay, so please look at povray.cpp (!)

/*****************************************************************************
*
* FUNCTION
*
*   Do_Cooperate
*
* INPUT
*   
* OUTPUT
*   
* RETURNS
*   
* AUTHOR
*
*   POV-Ray Team
*   
* DESCRIPTION
*
*   -
*
* CHANGES
*
*   -
*
******************************************************************************/

Sorry, but that's just [wasted] 312 bytes of source code telling 
essentially nothing just make it harder to keep an overview. 
[Don't want to start flame war and don't take that personally.]

>> Current_Line_Number and Current_Line.
>>   These are global vars and the latter is hard to grep because of
>>   the similarity with the first one. I don't use them as I use my
>>   own line buffer (9 lines).
> 
> Some code depends on them.  So be careful, things may fail in unexpected
> ways.
> 
I'll check that. 

>> Field_Render_Flag:
>>   Seems to be some strange thing skipping odd or even lines.
>>   Probably not 100% incompatible but I currently see no reason for
>>   supporting it. Maybe anyone has arguments [explain why useful].
> 
> It is an easy way to create animations for interlaced display devices (aka
> televisions).
> 
...and seems to do some sort of antialiasing?
I doubt it's worth the increased complexity for my patch, especially 
as most people probably watch previews on their computer screen. 
Maybe it can be added in the end. 

>> MOST CRITICAL is the detection if there is more than one object
>> inside the 8x8 block. A routine doing a quick test on that would
>> come quite handy. Problems may occur with partial reflection or
>> interior (ior) etc. but returning (false) positives for some parts
>> of the scene is acceptable. Unfortunately, I am not familiar with
>> the innermost workings of the POVRay "engine" so help is appreciated.
> 
> The object found is always on the intersection stack, so you can use that.
> 
...found in frame.h, struct istk_entry, struct istack_struct. 

So, if I understand you correctly, then the object hit by the ray 
is found on top of intersection stack (istk_entry.Object) 
once the ray is completely traced?
- How can I get access to the stack head. 
- What happens when the ray hits an object with 50% reflection? 
  (Thus the color of the pixel is determined by 2 objects.)
  How can I tell looking at the stack? 

The other point is that the algorithm would take most advantage if we 
can determine (quickly) if all the rays in the complete 8x8 _BOX_ hit 
the same object (without tracing the complete box). It's like shooting 
a ray with a diameter > 0. 
This way one can't leave out a horizontal 7 pixel thick cylinder which 
could currently be completely missed. 

How could one achieve that? It does not have to be 100% accurate, 
meaning that false positives are allowed (i.e. if we traverse an object 
with ior!=1). 

Wolfgang

Post a reply to this message